ETSI TS 124 629 vs.s.o (2009-06) 

Technical Specification 

Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

LTE; 

Explicit Communication Transfer (ECT) 
using IP Multimedia (IM) Core Network (CN) subsystem; 

Protocol specification 
(3GPP TS 24.629 version 8.3.0 Release 8) 




3GPP TS 24.629 version 8.3.0 Release 8 



1 



ETSI TS 124 629 V8.3.0 (2009-06) 



Reference 
RTS/TSGC-01 24629V830 

Keywords 
GSM, LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 



Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at 
http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2009. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 
for the benefit of its Members and of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 



2 



ETSI TS 124 629 V8.3.0 (2009-06) 



Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 



3 



ETSI TS 124 629 V8.3.0 (2009-06) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Explicit Communication Transfer (ECT) 8 

4.1 Introduction 8 

4.2 Description 8 

4.2.1 General description 8 

4.3 Operational requirements 8 

4.3.1 Provision/withdrawal 8 

4.3.2 Requirements on the transferor network side 8 

4.3.3 Requirements on the transferee network side 8 

4.3.4 Requirements on the transfer target network side 8 

4.4 Coding requirements 8 

4 . 5 Signalling requirements 9 

4.5.1 Activation/deactivation 9 

4.5.1 A Registration/erasure 9 

4.5. IB Interrogation 9 

4.5.2 Invocation and operation 9 

4.5.2. 1 Actions at the transferor UE 9 

4.5.2.2 Void 10 

4.5.2.3 Void 10 

4.5.2.4 Actions at the transferor AS 10 

4.5.2.4. 1 Invocation of ECT service 10 

4.5.2.4. 1 . 1 Prerequisite for invocation of the ECT service 10 

4.5 .2.4. 1 .2 Determine whether the ECT appUes 10 

4.5.2.4.1.2.1 REFER request received on a separate dialog 10 

4.5.2.4.1.2.2 REFER request received in the to be transferred dialog 10 

4.5 .2.4. 1 .2.2A Procedures for caU transfer with 3PCC 10 

4.5.2.4.1.2.3 Actions of ECT when invoked with a transfer request 11 

4.5.2.4.2 Subsequent procedures 11 

4.5.2.5 Actions at the transferee UE 12 

4.5 .2.5 . 1 Actions at the transferee UE (without 3PCC) 12 

4.5.2.5.2 Actions at the transferee UE (with 3PCC) 12 

4.5.2.6 Void 12 

4.5.2.7 Actions at the transferee AS 12 

4.5.2.7.0 Prerequisite for invocation of the ECT service 12 

4.5.2.7.1 Determine whether the ECT apphes 12 

4.5.2.7.2 Actions of ECT when invoked with a transfer request 13 

4.5.2.7.3 Actions of ECT when invoked again by the transferred communication 13 

4.5.2.8 Void 13 

4.5.2.9 Void 13 

4.5.2.10 Void 13 

4.5.2.11 Void 13 

4.5.2.12 Void 13 

4.5.2.13 Void 13 

4.5.2.14 Void 13 

4.5.2.15 Actions at the transfer target's AS 13 

4.5.2.16 Void 14 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 4 ETSI TS 1 24 629 V8.3.0 (2009-06) 

4.5.2.17 Actions at the transfer target's UE 14 

4.6 Interaction with other services 14 

4.6.1 Communication HOLD (HOLD) 14 

4.6.2 Terminating Identification Presentation (TIP) 14 

4.6.3 Terminating Identification Restriction (TIR) 14 

4.6.4 Originating Identification Presentation (OIP) 14 

4.6.5 Originating Identification Restriction (OIR) 14 

4.6.6 CONFerence Calling (CONF) 14 

4.6.7 Communication Diversion Services (CDIV) 14 

4.6.8 Malicious Communication IDentification (MCID) 15 

4.6.9 Anonymous Communication Rejection and Communication Barring (ACR/CB) 15 

4.6.10 Explicit Communication Transfer (ECT) 15 

4.6.10.1 Determine whether a previously transferred communication is transferred again 15 

4.6.10.2 Handling of transfer requests 15 

4.6.10.3 Actions when this ECT instance is invoked again by the transferred communication 15 

4.7 Interworking with other networks 16 

4.7.1 Void 16 

4.7.2 Void 16 

4.7.3 Void 16 

4.8 Parameter values (timers) 16 

4.9 Service configuration 16 

Annex A (informative): Signalling flows 17 

A.l Blind transfer 17 

A.2 Consultative transfer 19 

A.3 Blind call transfer with third party call control 20 

A. 4 Consultative call transfer with third party call control 22 

Annex B (informative): Example of filter criteria 24 

B . 1 Example of filter criteria for ECT 24 

Annex C (informative): Example charging model 25 

C. 1 Example of B REFER's A to C 25 

C.2 Example of A REFER's B to C 26 

Annex D (informative): Void 27 

Annex E (informative): Change history 28 

History 29 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 



5 



ETSI TS 124 629 V8.3.0 (2009-06) 



Foreword 

This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 

converged Services and Protocols for Advanced Networking (TISPAN) and originally published as 

ETSI TS 183 029 [1 1]. It was transferred to the 3rd Generation Partnership Project (3GPP) in January 2008. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the stage three (protocol description) of the Explicit Communication transfer (ECT) 
supplementary service, based on stage one and two of the ISDN ECT supplementary service. It provides the protocol 
details in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the 
Session Description Protocol (SDP). 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the ECT supplementary service. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version apphes. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Method". 

[3] IETF RFC 3892: "The Session Initiation Protocol (SIP) Referred-By Mechanism". 

[4] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[5] Void. 

[6] IETF RFC 3261 : "SIP: Session Initiation Protocol". 

[7] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalhng flows and 
message contents". 

[7 A] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[9] 3GPP TS 24.605: "Conference (CONE) using IP Multimedia (IM) Core Network (CN) subsystem; 

Protocol specification". 

[10] 3GPP TS 24.628: "Common Basic Communication procedures using IP Multimedia (IM) Core 

Network (CN) subsystem; Protocol specification". 

[II] ETSI TS 183 029 V2.5.0: "Telecormnunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); PSTN/ISDN simulation services: ExpUcit Communication 
Transfer (ECT); Protocol specification". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

ECT Session Identifier URI: PSI created and inserted by a ECT AS that resolves to the AS itself 

NOTE: If this URI contains correlation information it has to be constructed in such a way that it does not reveal 
identity information about any party involved in the transfer. 

transferee: party being transferred to the transfer target 

transferor: party initiating the transfer 

transfer target: party that the existing communication is transferred to 

NOTE: After transfer the transferee and the transfer target are in communication with each other. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



3GPP 


3"^ Generation Partnership Project (www.3gpp.org) 


ACR 


Anonymous Communication Rejection 


AS 


SIP Application Server 


CDIV 


Communication Diversion 


CONE 


CONFerence 


CSCE 


Call Session Control Function 


ECT 


Explicit Communication Transfer 


GRUU 


Globally Routable User agent URI 


HOLD 


communication HOLD 


IETF 


Internet Engineering Task Force 


IFC 


Initial Filter Criteria 


ISDN 


Integrated Services Digital Network 


MCID 


Malicious Call IDentification 


MGCF 


Media Gateway Control Function 


OCB 


Outgoing Communication Barring 


OIP 


Originating Identification Presentation 


OIR 


Originating Identification presentation Restriction 


PSTN 


Public Switch Telephone Network 


S-CSCE 


Serving-CSCE 


SIP 


Session Initiation Protocol 


TIP 


Terminating Identification Presentation 


TIR 


Terminating Identification presentation Restriction 


UE 


User Equipment 
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4 Explicit Communication Transfer (ECT) 

4.1 Introduction 

The service provides a party involved in a communication to transfer that communication to a third party. 

4.2 Description 
4.2.1 General description 

The Exphcit Communication transfer (ECT) service provides a party involved in a communication to transfer that 
communication to a third party. 

There are three actors active in a transfer, they are acting in the following roles: 

transferor: the party that initiates the transfer of the active communication that it has with the transferee; 
transferee: the party which stays in the conmiunication which is transferred; 

transfer target: the party which the conmiunication is transferred to and which replaces the transferor in the 

communication. 

There are two initial situations possible in which transfer shall be possible: 

- The transferor has no ongoing consultation communication with the transfer Target (Blind/Assured transfer). 

- The transferor has a consultation conmiunication with the transfer Target (Consultative transfer). 

The transferor AS takes care that it remains in the signalUng path even after the communication is transferred, this 
allows: 

- Classical charging models. 
Anonymization of the transfer Target. 

4.3 Operational requirements 

4.3.1 Provision/witlidrawal 

The ECT service may be provided after prior arrangement with the service provider or be generally available. 

4.3.2 Requirements on tlie transferor network side 

No specific requirements are needed in the network. 

4.3.3 Requirements on tine transferee network side 

No specific requirements are needed in the network. 

4.3.4 Requirements on tine transfer target network side 

No specific requirements are needed in the network. 

4.4 Coding requirements 

A user agent that wishes to use the ECT service (to act as a transferor): 
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- Shall support the REFER method as a cUent as specified in RFC 3515 [2]. 

- Shall support the Referred-By header as specified in RFC 3892 [3]. 

A user agent that is the transferred party in a communication transfer (acts as the transferee): 

- Shall support the REFER method as a server as specified in RFC 3515 [2]. 

- Shall support the Referred-By header as specified in RFC 3892 [3]. 

Shall support Replaces header field as a client as specified in RFC 3891 [4]. 
A user agent that is the transfer target in a conmiunication transfer: 

- May support the Referred-By header as a server as specified in RFC 3892 [3]. 

- May support the Replaces header as a server as specified in RFC 3891 [4]. 

4.5 Signalling requirements 
4.5.1 Activation/deactivation 

The ECT service is activated at provisioning and deactivated at withdrawal. 

4.5.1 A Registration/erasure 

The ECT service requires no registration. Erasure is not applicable. 

4.5.1 B Interrogation 

Interrogation of ECT is not applicable. 

4.5.2 Invocation and operation 
4.5.2.1 Actions at the transferor UE 

A UE that initiates a transfer operation shall: 

- Issue a REFER request in the original communications dialog, where: 

- The request URI shall contain the SIP URI of the transferee as received in the Contact header field. 

The Refer-To header field shall indicate the public address of the transfer Target. 

- If the transferor UE has a consultation communication with the transfer Target, a Replaces header field 
parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter. 

- The Referred-By header field can be used to indicate the identity of the transferor. When privacy was 
required in the original communications dialog and a Referred-By header field is included, the UE shall 
include a Privacy header field set to "user". 

After the REFER request is accepted by the other end with a 202 (Accepted) response, the transferor UE should get 
notifications of how the transferee's communication setup towards the transfer Target is progressing. 

When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have 
successfully setup a communication, the transferor UE may terminate the original communication with the transferee 
UE, by sending a BYE message on the original dialog. 
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4.5.2.2 Void 

4.5.2.3 Void 

4.5.2.4 Actions at the transferor AS 
4.5.2.4.1 Invocation of ECT service 

4.5.2.4.1 .1 Prerequisite for invocation of tine ECT service 

For ECT to be provided to end users acting as transferor, the end user's AS providing ECT shall be in the signalling 
path for all communications. 

4.5.2.4.1 .2 Determine winetlner tine ECT applies 

The transferor AS is the one executing the ECT service logic, which is invoked by the transferor sending a special 
REFER request. 

4.5.2.4.1 .2.1 REFER request received on a separate dialog 
ECT does not apply in this case. 

4.5.2.4.1 .2.2 REFER request received in the to be transferred dialog 

In order to know whether ECT service applies on a REFER request send by the served user, the following criteria shall 
apply before the ECT logic is executed: 

The REFER request's request-URI (transferee) is targeted at the same UE instance that is involved in the dialog. 

The REFER request's Refer-To header contains a URJ so that the method constructed from the URJ according to 
RFC 3261 [6] is equal to INVITE. 

Any REFER request that does not comply with these criteria shall not invoke the ECT service and is depending on 
operator policy: 

Rejected. 

Handled by another service. 
Proxied on. 



4.5.2.4.1 .2.2A Procedures for call transfer with 3PGG 

When a REFER request is received that invokes the call transfer service (see subclause 4.5.2.4.1), the AS shall follow 
procedures specified in 3GPP TS 24.229 [1] for 3PCC as an initiating B2BUA: 

terminate the REFER request from the transferor UE by sending a 202 (Accepted) response and subsequent 
NOTIFY requests according to IETF RFC 3515 [2]; 

generate an INVITE request without SDP content body based on the Refer-To header in the REFER request. The 
AS shall not include Replaces header in this INVITE request; 

send the INVITE request to the transfer target as either an initial INVITE if there is no consultative call between 
the transferor UE and the transfer target or a re-INVITE over the existing dialog if there is a consultative call 
between the transferor UE and the transfer target. 

Upon receiving a reliable response (reliable 18x response or 200 OK response) to the INVITE request from the transfer 
target UE with SDP offer information in the message body, the AS shall generate a re-INVITE request to the transferee 
UE. The re-INVITE shall include the media information in the SDP offer that matches what was received from the 
transfer target UE. The re-INVITE request is sent to the transferee UE over the existing dialog. 
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Upon receiving a reliable response (e.g., 200 OK) to the re-INVITE request from the transferee UE containing an SDP 
answer in the message body, the AS shall include the SDP answer into the next eligible request toward the transfer 
target as an answer to the original SDP offer. The next eligible request may be one of the following: 

- PRACK request for a reliable 18x response; or, 

- ACK request for 200 OK response. 

Upon successful completion of the 3PCC procedure between the transferee and the transfer target, the AS shall send a 
NOTIFY request to the transferor to indicate that the call transfer has been completed based on the REFER request. The 
AS shall not send NOTIFY requests on 200 (OK) responses received for requests other than INVITE requests. 



4.5.2.4.1 .2.3 Actions of ECT when invoked with a transfer request 

When a REFER request is received that invokes the ECT service (see subclause 4.5.2.4.1), ECT service shall perform 
the following actions: 

1) Create a new ECT Session Identifier URI addressed to this AS. The URI shall be created in such a way that a 
new dialog set up towards this URI can be easily correlated with the current REFER dialog. 

2) The AS stores the value of the Refer-To header field (transfer Target URI) ftom the REFER request and links 

it to the ECT Session Identifier URI. 

3) The AS replaces the Refer-To header field with the ECT Session Identifier URI (this ensures that the 
transferor AS remains in the loop when the transferee sets up the communication with the transfer Target). 

NOTE: If a Replaces header field parameter and/or a Require=replaces header field parameter are available in the 
URI contained in the Refer-To header field, the above step implies that they are not forwarded to the 
transferee. 

4) If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains 
a vaUd identity of the served user. If not it will replace the Referred-By header with a valid value matching the 
REFER request's P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to 
"user". The AS then stores the Referred-by header. 

5) If no Referred-By header is available in the request a Referred-By header is added that matches the REFER 
request's P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to "user". 

6) The AS sends the REFER request on to the transferee using basic communication procedures 
3GPP TS 24.229 LI J. 



If the AS receives a 403 Forbidden or 501 Not implemented in response to a REFER request, the AS of the initiator of 
the REFER request may initiate the special REFER handling procedures, according to 3GPP TS 24.628 [10]. 

If the AS receives a NOTIFY request with a sipfrag message body indicating a 420 Bad Extension as defined in 
RFC 3892 [3], the AS of the initiator of the REFER request may initiate the special REFER handling procedures 
according to 3GPP TS 24.628 [10]. 

As a network option, the AS of the initiator of the REFER request that has prior knowledge that the remote party is not 
allowed to receive or does not support the REFER method, may initiate the special REFER handling procedures 
directly, according to 3GPP TS 24.628 [10]. 

4.5.2.4.2 Subsequent procedures 



4.5.2.4.2.1 Actions of EOT when invoked again by the transferred communication 

When an INVITE is received targeted at the ECT Session Identifier URI created earUer when the served user requested 
transfer of an ongoing communication, ECT shall perform the following actions: 

0) If the stored transfer target URI linked to the ECT Session Identifier contains a Replaces header field 
parameter, then the AS inserts the Replaces header field in the INVITE request and: 

a) If the INVITE request does not contain a Requires header field, then the AS inserts a Requires header 
field in the INVITE request including a "replaces" token. 
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b) If the INVITE request does contain a Requires header field without a "replaces" token, then the AS inserts 
a Requires header field in the INVITE request including a "replaces" token. 

1) Strip all header field parameters and method parameter from the stored transfer Target URI and replace the 
request URI with the stripped version of the stored transfer Target URI Unked to the specific ECT Session 
Identifier URI. 

2) If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains 
a vaUd identity of the served user. If not it will replace the Referred-By header with a valid value matching the 
REFER request's P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to 
"user". 

3) If no Referred-By header is available in the request a Referred-By header is added that matches the REFER 
request's P-Asserted-Identity , and if "id" privacy was requested, include a Privacy header field set to "user". 

NOTE: If needed the AS can generate charging events to charge for the extra leg. 

4) The INVITE request is forwarded towards the transfer Target using basic communication procedures 
3GPPTS 24.229 [1]. 

4.5.2.4.2.2 Actions of ECT on failed REFER request 

4.5.2.5 Actions at the transferee UE 

4.5.2.5.1 Actions at the transferee UE (without 3PCC) 

When a REFER request is received in the context of a call transfer scenario (see subclause 4.5.2.4.1), the transferee UE 
shall perform the following steps: 

1) apply the procedure for holding the active conmiunication with the transferor as described in 
3GPP TS 24.610 [8] subclause 4.5.2.1; and 

2) apply normal REFER handling procedures according to 3GPP TS 24.229 [1]. 

4.5.2.5.2 Actions at the transferee UE (with 3PCC) 

The transfer target UE if not on a consultative call with the transferor UE, upon receiving an initial INVITE request 
with no SDP content, shall send reUable provisional responses with an SDP offer. The content of the SDP offer is 
derived base on service information received in the INVITE. 

The transfer target UE if on a consultative call with the transferor UE, upon receiving a re-INVITE request within the 
existing dialog with no SDP content, shall send 200 OK response according to with an SDP offer. The content of the 
SDP offer is derived based on the media characteristics of the existing consultative call. 

4.5.2.6 Void 

4.5.2.7 Actions at the transferee AS 

4.5.2.7.0 Prerequisite for invocation of the ECT service 

For ECT to be provided to end users acting as transferee, the end user's AS providing ECT shall be in the signalling 
path for all connmunications of the served user. 

4.5.2.7.1 Determine whether the ECT applies 

See subclause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an 
existing communication. 
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4.5.2.7.2 



Actions of ECT when invoked witli a transfer request 



When a REFER request is received in the context of a call transfer scenario (see subclause 4.5.2.4.1), it shall perform 
the following steps: 

5) Store the value of the Refer-To header field (used later to correlate the new communication with this REFER 

dialog). 

5a) Optionally it may store the value of the Referred-By header field, if it wants to ensure that the Referred-By is 
correct on the resulting INVITE request. 

6) Forward the request to the transferee according to basic communication procedures 3GPP TS 24.229 [1]. 

4.5.2.7.3 Actions of ECT wlien invoked again by tine transferred communication 

When an INVITE is received targeted at the SIP URI stored earlier when a transfer request was received targeted at the 
served user (transferee), ECT shall perform the following actions: 

0) Optionally the AS may check the following header fields in the received INVITE request: 

a) If a Referred-By header field is present in the INVITE, the AS may check if it matches the Referred-By 
header of the REFER stored earlier. If it does not match, depending on the policy of the service provider, the 
AS shall reject the INVITE request or replace the Referred-By header in the INVITE request with the value 
stored earlier. 

If a Referred-By header is absent in the INVITE, the AS shall insert a Referred-By header with the value 
stored earlier. 

1) Optionally the AS may generate charging events: 

a) To charge for the original communication between the transferee and the transferor, in case the transferee 
was the originating party in the original conmiunication. 

b) To switch of charging in case the transferee was the terminating party in the original communication. 

2) The INVITE is forwarded towards the transfer Target using basic communication procedures 
3GPPTS 24.229 [1]. 



4.5.2.8 Void 

4.5.2.9 Void 

4.5.2.10 Void 

4.5.2.11 Void 

4.5.2.12 Void 

4.5.2.13 Void 

4.5.2.14 Void 

4.5.2.15 Actions at tlie transfer target's AS 

Basic conamunication procedures according to 3GPP TS 24.229 [1] shall apply. 
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4.5.2.16 



Void 



4.5.2.17 Actions at the transfer target's U E 

Basic communication procedures according to 3GPP TS 24.229 [1] shall apply. 



4.6 

4.6.1 

No impact. 



No impact. 

4.6.3 

No impact. 

4.6.4 

No impact. 



Interaction with other services 
Communication HOLD (HOLD) 



4.6.2 Terminating Identification Presentation (TIP) 



Terminating Identification Restriction (TIR) 



Originating Identification Presentation (OIP) 



4.6.5 Originating Identification Restriction (01 R) 

Requirements relating to the Referred-By header field are described in subclauses 4.5.2.4.1.2.3 and 4.5.2.4.2.1. 

On the reception of an INVITE request from the transferee, the transferor AS shall deduce the "id" related privacy 

requirement that the transferee has indicated in the initial call between the transferee and the transferor; and shall 
include a Privacy header field containing the according value in the outgoing INVITE request. 

For the other transferee AS and the transfer Target AS there is no impact. 



4.6.6 CONFerence Calling (CONF) 

ECT shall not apply when the following criteria apply: 

- REFER request is received in an INVITE dialog with a conference focus, or a REFER request is received in an 
INVITE dialog and the Refer-to header field of the REFER request indicates the public address of active dialog 
to conference focus which is known by the AS providing ECT; and 

- The REFER is originated by the conference controller, the conference controller is the user that created and 
owns the conference. 

An AS can determine that an established INVITE dialog is terminated at a conference focus because according to 
3GPP TS 24.605 [9] it either: 

- has received a Ixx or 2xx response to the INVITE request with an "isfocus" feature parameter in the Contact 
header field; or 

- has received an INVITE with an "isfocus" feature parameter in the Contact header field. 



4.6.7 Communication Diversion Services (CDIV) 

No impact. 
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4.6.8 Malicious Communication IDentification (IVICID) 

No impact. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

For the transferor AS the following appUes: 

- Shall not accept transfer requests with a transfer Target that is barred by the served users Outgoing 
Communication Barring (OCB) rules. 

- For the transferee AS and the transfer Target AS there is no impact. 

4.6.10 Explicit Communication Transfer (ECT) 

4.6.1 0.1 Determine whether a previously transferred communication is transferred 
again 

See subclause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an 
existing communication. 

Additionally the following criteria should apply for this interaction case to apply: 

The INVITE dialog on which the REFER is received is a previously transferred communication, for which the 
current ECT instance had the Transferor role. 

4.6. 1 0.2 Handling of transfer requests 

When a REFER request is received and the criteria of subclause 4.6.10.1 apply, then the AS shall perform the following 
steps: 

1) Create a new ECT Session Identifier URI addressed to this AS. The URI shall be created in such a way that a 
new dialog set up towards this URI can be easily correlated with the current REFER dialog. 

2) The AS stores the value of the Refer-To header field (transfer target) from the REFER request and Unks it to 
the ECT Session Identifier URI. 

3) The AS replaces the Refer-To header field with the ECT Session Identifier URI from step 1). (This ensures 
that this AS remains in the loop when the transferee sets up the communication with the transfer target.). 

4) The AS forwards the REFER request to the transferee using basic communication procedures 
3GPPTS 24.229 [1]. 

4.6.1 0.3 Actions when this ECT instance is invoked again by the transferred 

communication 

When an INVITE is received targeted at the ECT Session Identifier URI created earlier in subclause 4.6.10.2, the AS 
shall perform the following actions: 

1) The AS replaces the request URI with the stored Refer-To header field value linked to the specific 
ECT Session Identifier URI. 

NOTE: If needed the AS may generate charging events to charge for the extra leg. 

2) The AS forwards the INVITE request towards the transfer target using basic conununication procedures 
3GPPTS 24.229 [1]. 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 16 

4.7 Interworking with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 

4.8 Parameter values (tinners) 

No specific timers are required. 

4.9 Service configuration 

Not applicable. 
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Annex A (informative): 
Signalling flows 

A.1 Blind transfer 

Figure A. 1 signalling flow shows a blind transfer scenario, whereby the REFER request is sent on the existing INVITE 
dialog between A and B. 



Transferee 



Transferror 



Transfer Target 



UE-A 



AS-A 

(P-CSCF, 
l-CSCF, S-CSCF, 
AS) 



AS-B 

(P-CSCF, 
l-CSCF, S- 
CSCF, AS) 



UE-B 



AS-C 

(P-CSCF, 
l-CSCF, S- 
CSCF, AS) 



Media streams have been setup between A and B, AS-A and AS-B are in the 
signalling patii. See "Basic Call" procedure. 




This allows B to 
pick up the 
existing session 
when the transfer 
fails. 




dialog 1; 
INVITE usage 
terminates 



IVIedia between A and B are Terminated 



dialog 1; 
REFER usage 



dialog 2 



13. NOTIFY(100 Trying) 



14. N0TIFY(1 00 Trying) 



19. INVITE 
To: private URL 



100 Trying 



14.1 



26. 200 OK 



100 Trying 



15. NOTIFY(100 
Trying) 



AS-B stores the "Refer-To" information 
and replaces it with ECT Session 
Identifier URIs, so that UE-A will not 
know the identity of UE-C and the AS- 
B is kept in the route. This also solves 
the charging problem. 



AS-B replaces theECT 
Session Identifier URI with 
UE-C's stored contact UR!. 
ECT Session Identifier URI 
also allows AS-B to correlate 
this INVITE with the original 
session that needs to be 
transfered. 



21. INVITE To: C 



Trying 



21.1 



100 Trying 



23. 200 OK 



Media streams between A and C 



dialog 1; 
REFER usage 



31. NOTIFY(200 OK) 



32. NOTIFY(200 OK) 



33. NOTIFY(200 OK) 



Figure A.I : Blind transfer 



1. A multimedia session exists between A-B. B initiates transfer A to C, by sending REFER request To: UE-A with 
Referred-To: UE-C, Referred-By: UE-B. The REFER request is send in the existing dialog that between A and B. 
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1.1 Upon reception of the REFER request, AS-B must check whether there is no outgoing call barring active from B to 
C. Because B is charged for the call from B-C when A is referred to C, when outgoing call barring is active from B-C 
the REFER request is rejected. 

AS-B checks whether B is allowed to transfer calls, if it is allowed to transfer the call then AS-B generates an ECT 
Session Identifier URI, addressed to itself, with the new destination information and billing information that will be 
needed for the new session. It replaces the Refer-To value with the ECT Session Identifier URI. This ensures that: 

AS-B will remain in the loop. 

2. The REFER request is sent on to AS-A. 

2. 1 AS-A checks whether it is allowed to transfer A. 

3. The REFER request is sent on to A by AS-A. 

4. The REFER request is accepted by A's UE. 

4.1, 13.1, 31.1 AS-A can use result messages and notifications caused by the REFER request to track success of refer 
and take appropriate actions. The AS-A can ensure that header fields that where replaced with other content are 
recreated with the original content on the way back. 

5.1, 8.1, 32.1 AS-B can use this to track success of the REFER request and take appropriate actions. The AS-B can 
ensure that header fields that where replaced with other content are recreated with the original content on the way back. 

7. Since the REFER request was accepted in 6. UE-B tenninates the existing INVITE dialog by sending a BYE to UE- 
A. 

19. The UE-A initiates a new session by sending an INVITE request to AS-B's ECT Session Identifier URI (which 
represents UE-C). 

19.1 AS-A routes the INVITE request to AS-B using the AS-B's ECT Session Identifier URI using normal SIP 
routing procedures. Normal charging from A to B applies. 

20. 1 Upon receiving the INVITE request to the ECT Session Identifier URI that was inserted by the AS-B, the AS-B 
replaces it with the Request URI of C and creates an INVITE targeted towards UE-C. 

In this scenario it can be assumed that there is no active outgoing call barring towards UE-C, because the REFER was 
accepted by AS-B. The ECT Session Identifier URI has a limited validity time to ensure that no future barring is 
violated. 

Also the Referred-By: header field is verified or filled in with the original uncodified values. Then the INVITE request 
is forwarded to UE-C using normal routing procedures. 

21.1, 23.1 Normal terminating services apply for UE-C. The call will be treated as a call from A-C regarding call 
policies. 

25.1 AS-A. Normal response handling applies. 
27.1 AS-A. Normal ACK handling appUes. 

28.1 AS-B replaces all codified values and ECT Session Identifier URI 's with stored values. 
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A.2 Consultative transfer 



Figure A.2 signalling flow shows a consultative transfer scenario. 

Transferee Transferror 



Transfer Target 



UE-A 



AS-A 

(P-CSCF, 
l-CSCF, S-CSCF, 
AS) 



AS-B 

(P-CSCF, 
l-CSCF, S- 
CSCF AS) 



UE-B 



dialog 1 

INVITE usage 



L L rri; 

Media streams have been setup between A and B, AS-A and AS-B are in the 
signalling path. See "Basic Call" procedure. 

B puts A on hold, see "Session Hold/Resume" Procedure 

Media between A and B are on Hold i 



AS-C 

(P-CSCF, 
l-CSCF, S- 
CSCF AS) 




I 

I ^ 



This allows B to 
pick up the 
existing session 
when the transfer 
fails. 



dialog 2 



dialog 1 

REFER usage 



dialog 1 

REFER usage 



dialog 3 



dialog 3 



dialog 2 



dialog 1 

REFER usage 



dialog 1 

INVITE usage 



AS-B Stores the "Refer-To" and 
"Referred-By" information and 
replaces it with ECT Session 
Identifier URIs, so that UE-A will not 
know the identity of UE-B or UE-C 
and the AS-B is kept in the route. 
This also solves the charging 
problem. 



B uses standard "Basic Call" procedure to setup a call with C 



r 



Media streams between B and C 



4. 202 Accepted 



2. REFER 

private-URL 




B puts C on hold, see "Session Hold/Resume" Procedure 

~~ ~~~~~ ~JL~~~~ ------ ~rL 

Media streams between B and C are on Hold 

I - r 



1. REFER Refer-To: 
C?Replaces=dlalog 2 



7. NOTIFY(100 Trying) 



5. 202 Accepted 



8. NOTIFY(100 Trying) 



6. 202 Accepted 



S.l 



9. NOTIFY(100 Trying), 



10. 200 OK 



A puts B on hold, to avoid dual codec instances in A's UE i 



B initiates the transfer. By referring A 
to C. 

It is send in the target dialog so that 
the Transferee can correlate this 
dialog with the original to be 
transfered dialog. This ensures that 
the receiver of the REFER request 
can authenticate the request. 



AS-B replaces the ECT 
Session Identifier URI's with 
UE-C's stored contact URI. 
ECT Session Identifier URI 
also allows AS-B to correlate 
this INVITE with the original 
session that needs to be 
transfered. 



This allows 8 to 
pick up the 
existing session 
when the transfer 
fails. 




31.NOTIFY(200OK) 



32. NOTIFY(200 OK) 



* Media streams between B and clare Terminated 



33. NOTIFY(200 OK) 



dialog 2 is automatically 
terminated because it is 
replaced. See [RFC3891] 



Media between A and B are Terminated 



Figure A.2: Consultative transfer 
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1. A multimedia session exists between A-B and between B-C. B initiates transfer A to C, by sending REFER method 
To: UE-A GRUU with the Refer-To: UE-C?Replaces=dialog2&Require=replaces, Referred-By: UE-B. The REFER 
reuses the dialog that exists from A-B. 

1.1 Upon reception of the REFER operation AS-B must check whether there is no outgoing call barring active from B to 
C. Because B is charged for the call from B-C when A is referred to C, when outgoing call barring is active from B-C 
the REFER is rejected. 

AS-B checks whether B is allowed to transfer calls, if it is allowed to transfer the call then AS-B generates an ECT 
Session Identifier URl, addressed to itself, with the new destination information and billing information that will be 
needed for the new session. It replaces the Refer-To value with the ECT Session Identifier URI. This ensures that AS-B 
will remain in the loop. 

2. The REFER to method is sent on to AS-A. 

2.1 AS-A checks whether it is allowed to transfer A. 

3. Refer is sent on to A by AS-A. 

4.1, 7.1, 31.1 AS-A can use result messages and notifications caused by REFER to track success of REFER and take 
appropriate actions. The AS-A can ensure that header fields that where replaced with other content are recreated with 

the original content on the way back. 

5.1, 8.1, 32.1 AS-B can use this to track success of REFER and take appropriate actions. The AS-B can ensure that 
header fields that where replaced with other content are recreated with the original content on the way back. 

13. UE-A initiates a new session by sending an INVITE to AS-B's ECT Session Identifier URl (which represents UE- 
C). 

13.1 AS-A checks whether A is allowed to use the Replace extension and routes the INVITE to AS-B using the AS- 
B's ECT Session Identifier URI using normal SIP routing procedures. Normal charging from A to B appUes. 

14.1 Upon receiving the INVITE to the ECT Session Identifier URl that was inserted by the AS-B, the AS-B replaces 
the Request URl and creates an INVITE targeted towards UE-C. Further AS-B inserts a Replaces header field with the 
value of the Replaces parameter of the stored transfer Target URI if it is available, which will allow the new session to 
take the place of the existing session between B and C. 

In this scenario it can be assumed that there is no active outgoing call barring towards UE-C, because UE-B was able to 
setup a call to UE-C in the first place. However when there was no consultation call to UE-C, there is an issue but this is 
solved at the initial reception of the REFER from UE-C and not at this stage. 
The INVITE is forwarded to UE-C using normal routing procedures. 

15.1, 17.1 Normal terminating services apply for UE-C. The call will be treated as a call from A-C regarding call 
policies. AS-C checks whether the Replace mechanism is used. 

19.1 AS-A. Normal response handling applies. 

21.1 AS-A. Normal ACK handhng apphes . 

22. 1 AS-B replaces all codified values and the ECT Session Identifier URI with stored values. 

25. UE-C terminates dialog 2 as consequence of normal Replace procedures according to RFC 3891 [4]. 



A.3 Blind call transfer with third party call control 

Figure A.3 depicts a scenario where UE-1 and UE-2 are in an active call. UE-1 decides to blind transfer UE-2 to UE-3. 
In this scenario, UE-3's initial offer (Ol) is presented to the AS (acting on behalf of UE-1) in an 18x method. Since UE- 
2 is already on hold, the INVITE to stimulate the UE-3 offer is sent first. This expedites the off-hold processing of UE- 
2. 

Note that 3PCC as shown in this call flow is also sometimes refered to as "REFER interworking". 
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UE-1 




P-CSCF 




S-CSCF 




AS 



















UE-2 

I 



UE-3 



1. UE-1 and UE-2 are in a normal call 
2. UE-1 Puts UE-2 on hold 



3. REFER (Refer-To: 
^ 


4. REFER (Refer-To: 
UE=3) ». 


5. REFER (Refer-To: 
UE=3) ». 


^ 8. 202 Accepted 


^ 7. 202 Accepted 


^ 6. 202 Accepted 


11. NOTIFY (100 


10. NOTIFY (100 


9. NOTIFY (100 


Tryrng) 

12. 200OK(NOTIF\)^ 


Tryrng) 

13. 200 OK(NOTIF\;^ 


Tryrng) 

14. 200 OK (NOTIFY^ 


15. BYE ^ 


16. BYE ^ 


17. BYE ^ 


^ 20. 200 OK (BYE) 


^ 19. 200 OK (BYE) 


^ 18. 200 OK (BYE) 


^2. NOTIFY (200 OK) 


^1. NOTIFY (200 OK) 


^0. NOTIFY (200 OK) 


33. 200OK(NOTIFY|^ 


34. 200 OK (NOTIF\j^ 


35. 200 OK (NOTIFY^ 









21.INVITE(no sfeP) 
22. 18xNNN(o{l) 



23. re-INVITE(OI) 



24. 200 OK (A1) 



25. ACK (INVITE) 











1 

27. 200OK(PRA(pK) 
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1 

28. 200 OK (INVITE) 







1 

29. ACK 1 






1 

1 Media between UE 
1^ and UE-3 





Figure A.3: Blind Call Transfer with 3PCC 

UE-1 and UE-2 are on an active call. UE-1 decides to blind transfer UE-2 to UE-3. 
1: UE-1 and UE-2 are in a normal call. 

2: UE-1 first puts UE-2 on hold before initiating the blind call transfer. 

3 to 5: UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by UE- 
I's S-CSCF since the AS is included in the signaling path between UE-1 and UE-2 due to initial filter triggers in the 
original call setup process. 

6 to 8: The AS acknowledges the REFER request with 202 Accepted response. 

9 to 14: The AS can optionally notify UE-1 of the REFER processing status by sending NOTIFY. 

15 to 17: UE-1 sends BYE to UE-2 to terminate the call between them. 

18 to 20: The AS acknowledges the BYE with 200 OK (BYE) toward UE-1 . 

21: The AS sends an INVITE to the URl contained in the Refer-To header to establish a call with UE-3. The AS picks 
the non-hold UE for first contact. The INVITE contains no SDP so that the UE-3 may present the initial offer, Ol. 

22: UE-3 extends the initial offer (Ol) in a 18x message. The offer includes mode=send/recv. 

23: AS-1 sends a re-lNVlTE with offer, Ol received from UE-3, to UE-2. 

24: UE-2 is on-hold when it receives the SDP offer with send/receive from UE-3. This directs UE-2 to go off-hold and 
UE-2 responds with an answer (Al) with mode=send/receive in a 200 OK for the re-INVITE. 

25: AS-1 acknowledges the INVITE with an ACK (INVITE). 

26: The PRACK message for the ISx (message 22) contains the answer (Al) from UE-2. 
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27: UE-3 acknowledges with a 200 OK for the PRACK. 

28: UE-3 acknowledges the INVITE with a 200 OK for the INVITE 

29: AS-1 closes the INVITE with ACK to UE-3. 

Media between UE-2 and UE-3 

30 to 32: The AS notifies UE-1 of the transfer complete with a NOTIFY (200 OK). 
33 to 35: UE-1 acknowledges the NOTIFY with 200 OK (NOTIFY). 



A.4 Consultative call transfer with third party call control 

Note that 3PCC as shown in this call flow is also sometimes refered to as "REFER interworking". 
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Figure A.4: Consuitative Transfer with 3PCC 



UE-1 and UE-2 are on an active call. UE-1 decides to transfer UE-2 to UE-3, but before the actual transfer happens, 
UE-1 consults with UE-3 first for permission to transfer the call. 



ETSI 



3GPP TS 24.629 version 8.3.0 Release 8 23 ETSI TS 1 24 629 V8.3.0 (2009-06) 

1 : UE-1 and UE-2 are in a normal call. 

2: UE-1 first puts UE-2 on hold before initiating the call transfer. 

3 to 11: UE-1 estabhshes call with UE-3 following normal procedures and gets UE-3's permission to transfer UE-2. 
12: UE-1 optionally puts UE-3 on hold before the call transfer. 

13 to 15: UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by 
UE-l's S-CSCF since the AS is included in the signahng path between UE-1 and UE-2 due to initial filter triggers in the 
original call setup process. 

16 to 18: The AS acknowledges the REFER request with 202 Accepted response. 
19 to 24: The AS notifies UE-1 of the REFER processing status by sending NOTIFY. 
25: The AS sends re-INVITE to UE-3 with no SDP information. 

26: UE-3 returns 200 OK to the AS with an SDP offer (Ol). The SDP offer proposes the call to be taken off hold. 
27: The AS sends re-INVITE to UE-2 with the same SDP offer (Ol). 
28: UE-2 sends 200 OK with SDP answer (Al) to the AS. 

29: The AS sends ACK to UE-2 with the SDP answer (Al). Now the end-to-end offer/answer exchange between UE-2 
and UE-3 is completed. 

30: The AS sends ACK to UE-3 to acknowledge the 200 OK response. 

31 to 36: UE-2 sends NOTIFY to UE-1 to notify the status of the REFER processing. 

37 to 42: UE-1 sends BYE and terminates the call leg between UE-1 and UE-2. 
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Annex B (informative): 
Example of filter criteria 

B.1 Example of filter criteria for ECT 

This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

When the initial request matches the conditions of the next unexecuted IFC rule for the served user which points to the 
ECT service, the communication is forwarded to the AS. 

An example of an Initial Filter Criteria (IFC) Trigger Point configiu^ations under the assumption that the ECT service is 
a standalone service that can be invoked by a very specific trigger point active at the destination S-CSCF: 

- Method="E^ITE". 

NOTE 1: The coding of the Initial Filter Criteria is described in 29.228 [7] and 29.229 [7 A]. 

NOTE 2: When the REFER is sent on an existing dialog, no IFC processing will be performed, because this is a 

subsequent request on an existing dialog. It follows that when this scenario has to be supported, that then 
all signalling has to traverse through the AS. 
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Annex C (informative): 
Example charging model 

C.1 Example of B REFER's A to C 

This scenario is added to show that the solution presented in the present document is able to support classical charging 
models. Assumption in this scenario is that A originated the original call and is thus charged for the initial A-B 
communication. 

B REFERS A TO C 

correl. correl. 




Transfer Target 
* UE-C 



» A->B: INVITE/OK A:A-B 
.£_ B->A: REFER 
^\ A->C: INVITE 

Figure C.1 : Example of B REFER's A to C 



Table C.1 



Initial Session Initiated By 


Initial Session A-B 


Transferred Session 






Transfer Target C 


A=Transferee 


Transferee (A); A-B 


Transferee (A): A-B 






Transferor (B): B-C 


A=Transferor 


Transferor (A): A-B 


Transferor (A): A-B 



Transferor (A): A-C 
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C.2 Example of A REFER's B to C 

This scenario is added to show that the solution presented in the present document is able to support classical charging 
models. Assumption in this scenario is that A originated the original call and is thus charged for initial A-B 
communication. 



A REFERS B TO C 



correl. 
correl. with 
with ECT 
Target- Session / 
Dialog Identifie/ 



Charge A-B ■^ 
Charge A-C 



Wrrel. 

correl. with 
with ECT 
Target- Session 
Dialog Identifier 



mm [Of 



The no charge case is only valid in this transfer 

scenario. 

Criteria: 

- This is the Transferee's AS 

- The Transferee is the terminating party in the 
session that is being transferred. 




;scF- 
c 



A->B: INVITE/OK A:A-B 
A->B: REFER 
B->C: INVITE 

Figure C.2: Example of a REFER's B to C 
Table C.2 



Transfer Target 









UE-C 



Initial Session Initiated By 


Initial Session A-B 


Transferred Session 
Transfer Target C 


A=Transferee 


Transferee (A): A-B 


Transferee (A): A-B 
Transferor (B): B-C 


A=Transferor 


Transferor (A): A-B 


Transferor (A): A-B 
Transferor (A): A-C 
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Annex D (informative): 
Void 
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Annex E (informative): 
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